The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
In packet-switched networks consisting of multiple network elements such as routers and switches, the Resource Reservation Protocol (“RSVP”) may be used to reserve routing paths for the purpose of providing optimized routing of specified kinds of network traffic, such as voice traffic. RSVP is described in Braden et al., “Resource ReSerVation Protocol (RSVP)—Version 1, Functional Specification,” Request for Comments (RFC) 2205 of the Internet Engineering Task Force (IETF), September 1997.
MPLS (Multi-Protocol Label Switching) Traffic Engineering has been developed to meet data networking requirements such as guaranteed available bandwidth. MPLS Traffic Engineering exploits modern label switching techniques to build guaranteed bandwidth end-to-end circuits through an IP network of label switched routers (LSRs). These circuits are a type of label switched path (LSP) and thus generally referred to as MPLS Traffic Engineering LSPs. MPLS Traffic Engineering LSPs traverse a series of nodes and links that interconnect them. MPLS Traffic Engineering protocols define a link to be a logical construct that represents physical resources that interconnect label switched routers. The information about a particular link including the available link bandwidth is used in determining the routes of LSPs and signaling their establishment. Admission control is performed to ensure that link capacity is not exceeded during setting up of an LSP. Extensions to RSVP for MPLS Traffic Engineering are described in RFC 3209 and RFC 3473 full citations of which are: “Extensions to RSVP for LSP Tunnels”, D. Awduche, et al, RFC 3209, December 2001; “Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions”, RFC 3473, L. Berger, et al, January 2003.
MPLS TE preemption consists of freeing the resources of an already established LSP and assigning them to a new LSP. The freeing of these resources causes a traffic disruption to the LSP that is being preempted. Soft preemption is an extension to the RSVP TE protocol to minimize and even eliminate (in case no drops happen due to congestion) the traffic disruption over the preempted LSP. RFC 5712, “MPLS Traffic Engineering Soft Preemption”, M. Meyer, et al, January 2010 describes soft preemption in an MPLS network. Today since decision to compute the set of candidate LSPs for soft preemption is local to a node in the network, setting up of a high priority LSP can result in an excessive number of LSPs being preempted leading to a major network disruption.
Throughout this document, familiarity with all the foregoing references is assumed. In one respect, these extensions enable RSVP to interoperate with processes that implement Multi-Protocol Label Switching (MPLS).